AWSアカウントを作ったら最初にやるべきこと ～令和元年版～
はじめに
中山（順）です
4年ほど前にこの記事のタイトルと同じテーマで資料を作成したことがあるのですが、古い内容があったり新しいサービスのことが含まれていなかったりするので改めてまとめてみました。令和だし！
その時の資料はこちらです（クラスメソッドにジョインするくらい2年前です）。
AWSアカウントを作ったら最初にやるべきこと
- サインアップ
- （業務利用の場合）非個人メールアドレスでサインアップ
- サポートプランの確認
- ID管理 / 権限管理
- CloudTrailの有効化
- ルートアカウントのMFA設定
- IAM User / IAM Groupの作成
- パスワードポリシーの設定
- GuardDutyの有効化
- Security Hubの有効化
- 請求
- IAM Userによる請求情報へのアクセス許可
- 支払通貨の変更
- Budgetの設定
- Cost Explorerの有効化
- Cost Usage Reportの出力
- コスト配分タグの設定
- その他
- 代替連絡先の設定
- Trusted Advisorの通知設定
- Configの有効化
- Personal Health Dashboard によるイベント監視
- 有効なリージョンの確認
- 【追加】準拠法／管轄裁判所の変更
改版履歴
- 2019.05.20 Artifactによる準拠法／管轄裁判所の変更について追加（はてブでコメントいただいたid:Kilさん、ありがとうございます）
1.（業務利用の場合）非個人メールアドレスでサインアップ
タイトルが「AWSアカウントを作ったら～」なのに、サインアップのところから言及していきます。
AWSアカウントを作成する際、以下の情報が必要になります。
- メールアドレス
- クレジットカード情報
- 本人確認に可能な電話番号（音声通話もしくはSMS）
このうち、メールアドレスは個人のものではなく、メーリングリストのような複数（ただし、信頼できる限られたメンバー）が受信できるメーリングリストが望ましいと考えます。
サインアップした直後はこのメールアドレスをIDとするルートアカウントのみがAWSアカウントを操作できます。 基本的には後述するIAM User等でAWSアカウントを操作することにあるのですが、ルートアカウントでしか操作できないタスクが存在します。
AWS Tasks That Require AWS Account Root User Credentials
万が一、個人のメールアドレスでアカウントを作成し、その方が退職してルートアカウントでログインできなくなると上記のタスクを実行できなくなります。 特権は誰でも利用できると問題がありますが、一人しか利用できないのも問題があります。
2.サポートプランの確認
サインアップ時、サポートプランを選択できます。 プランによって問い合わせ時のレスポンスタイムなどが異なりますので、ビジネス上の要件にマッチしたプランを選択しましょう。
3.CloudTrailの有効化
ここからはセキュリティに関する事項をご紹介します。
まずは、CloudTrailの有効化をしましょう。
CloudTrailは、AWSのAPIに対する操作ログを取得するサービスです。
CloudTrailを有効化することによって、AWSアカウントに対して「誰が」「いつ」「何を」したのか確認することができます。 実際のログファイルは、ドキュメントのサンプルなどでご確認頂けます。
これにより、監査への対応やトラブル発生時の原因調査（誤操作の特定など）が可能になります。 また、内部不正に対する抑止力にもなるでしょう。
ただし、CloudTrailの無効化やログの改ざん／削除などが行われないよう権限の付与には注意してください。
また、全てのサービス／アクションをサポートしているわけではありません。
CloudTrail Supported Services and Integrations
CloudTrail Unsupported Services
必要に応じて、ログを参照／解析できるように手順を確認してきましょう。 個人的には、CloudTrailのコンソールで十分なケースが多いと思っていますが、必要に応じてAthenaによるクエリやCloudWatch Logs Insightsの利用を検討しましょう。
Sample Queries (Queries for CloudTrail Logs)
4.ルートアカウントのMFA設定
ルートアカウントに対してMFAの設定を行いましょう。
ルートアカウントには、AWSアカウントに対するあらゆる操作を実行可能で、この権限を減らすことができません。 そのため、認証要素を追加して乗っ取られないように保護する必要があります。 RFC6238 (Time-based One-time Password) に準拠したデバイスとU2F security keyを利用することができます。
Enable MFA on the AWS Account Root User
パスワードを忘れた際にはサインアップ時に設定したメールアドレスを利用してリセットすることができますが、MFAはどうでしょうか？ MFAのデバイスやキーを紛失した際には、アカウントに設定されたメールアドレスおよび電話番号を利用してリセットすることが可能です。
What If an MFA Device Is Lost or Stops Working?
このような事態に備え、メールアドレスと電話番号は利用可能なものを設定するようにしましょう。
5.IAM User / IAM Groupの作成
AWSで構築や運用を行うメンバーに付与するIAM Userの作成を行いましょう。 また、IAM Userへ権限を付与するためにIAM Groupを作成しましょう。
すでに述べたように、ルートアカウントの権限を制限することができません。 また、ルートアカウントを共有すると、CloudTrailでログを保存していても「だれが」操作をおこなったのか特定できなくなってしまいます。
そのため、AWSアカウントを操作する各個人にIAM Userを発行します。
あわせて、IAM Userに権限を付与するためにIAM Groupを作成します。 IAM Groupに対して権限を付与し、IAM UserをIAM Groupのメンバーにすることで、IAM Userに権限を付与することができます。 IAM Userに直接権限を付与することもできますが、IAM User数が増えるほど管理が困難になります。
Use Groups to Assign Permissions to IAM Users
次にIAM Groupに対して権限を付与しますが、その際には「基本的に」最小権限を付与しましょう。 とはいうものの、いきなり厳密な権限定義を行うのは難しいと思います。 落としどころとしては、AWSが事前定義する管理ポリシーを利用するといいと思います。
Get Started Using Permissions With AWS Managed Policies
また、強い権限を付与するIAM Userに対してはMFAを有効化しましょう。
Enable MFA for Privileged Users
これらについては、IAM Best Practicesに記載されていますので、必要に応じて参照してください。
6.パスワードポリシーの設定
パスワードポリシーを変更し、パスワードが推測されるリスクを軽減しましょう。
パスワードポリシーでは、パスワードに含める必要のある文字種別を指定したり、パスワードの長さや有効期限を設定できます。
Setting an Account Password Policy for IAM Users
Configure a Strong Password Policy for Your Users
パスワードのローテーションに関しては定期的な変更を推奨しないというケースも増えておりますが、そのことだけを切り取るのではなく、OTPなど認証要素の追加や使い回しをしないなど適切な対策をあわせて実施しましょう。
7.GuardDutyの有効化
GuardDutyはAWSアカウントにおける不審なアクティビティを検知／通知してくれるサービスです。
以下のデータソースから不審なアクティビティを検知してくれます。
- AWS CloudTrail event logs
- VPC Flow Logs
- DNS logs
検出できるイベントは以下のドキュメントを参照してください。
GuardDuty Active Finding Types
検出されたイベントはCloudWatch Events経由で通知することも可能です。
Monitoring Amazon GuardDuty Findings with Amazon CloudWatch Events
8.Security Hubの有効化
Security Hubは2019年5月19日現在プレビュー中です
Security HubはAWSアカウントのセキュリティ状態を集約して表示できるサービスです。 GuardDuty, Inspector, Macieのイベントを集約したり、CIS AWS Foundations Benchmarkに基づいたリスクを表示してくれます。
不審なアクティビティや問題のある設定（および設定漏れ）があればまとめて表示してくれますので、有効化しておきましょう。
9.IAM Userによる請求情報へのアクセス許可
ここからはコスト／請求に関する内容となります。
まず、IAM Userに対してコストに関する情報へのアクセスを許可します。 デフォルトではルートアカウントしかコストに関する情報へアクセスできません。
コスト管理は重要な定常タスクですので許可しておきましょう。
Granting Access to Your Billing Information and Tools
10.支払通貨の変更
昔は登録したクレジットカードへの請求はドルで行われてました（適用する為替レートはクレジットカード会社が決定する）。 しかし、現在は複数の通貨から選択することが可能です。 日本円を選択することで、外貨取扱手数料に相当する費用を削減することが可能です。
念のため補足しますが、AWSの料金がドルベースなのは変わりません。 日本円による請求額自体は請求時点の為替レートで決まります（適用する為替レートはAWSが決定する）。
Changing Which Currency You Use to Pay Your Bill
11.Budgetの設定
BudgetはAWSアカウントのコストを監視するためのサービスです。
予め設定したコストに到達したときもしくは到達することが予測されるときに通知することができます。 また、一部の課金要素（データ転送量など）に限定して使用量を監視することができます。
毎月の予算を超えないか監視しましょう。
Managing Your Costs with Budgets
12.Cost Explorerの有効化
Cost Explorerは、AWSの利用状況を可視化／分析できるサービスです。 サービス毎のコストや月ごとのコストの推移を確認できます。 また、最近ではリザーブドインスタンスの推奨を表示することができます。
Accessing Reserved Instance Recommendations
ただし、デフォルトでは無効なのでアカウント作成時に有効化しましょう。
13.Cost Usage Reportの出力
簡易的なコスト分析であればCost Explorerで十分ですが、より詳細な分析を行いたい場合にはCost Usage Reportを出力しましょう。
通常はS3にCSV形式（GZIP圧縮）で出力されます。 Athenaと連携するように指定した場合には、parquetで出力されます。
Creating an AWS Cost and Usage Report
14.コスト配分タグの設定
コストを詳細に分析する際、独自の切り口で分析したいというケースがあると思います。 その際、コスト配分タグを有効化しましょう。
コスト配分タグにはAWSが生成するタグとユーザー定義のタグの2種類があります。 ユーザー独自の切り口で分析したい場合にはユーザー定義タグを利用しましょう。 ユーザー定義のコスト配分タグを有効化する際には、予めリソースの作成とタグ付けを行ってから実施しましょう。
Activating the AWS-Generated Cost Allocation Tags
Activating User-Defined Cost Allocation Tags
15.代替連絡先の設定
AWSアカウントには、サインアップ時に設定した連絡以外の連絡先を設定できます。
具体的には、以下の三種類の代替連絡先を設定できます。
- Billing
- Operations
- Security
特にSecurityは認証情報の漏洩時などにAbuse Teamから連絡が来る可能性があるため、セキュリティインシデントの専任チーム等がある場合にはその連絡先などを設定するといいのではないでしょうか。
Adding, Changing, or Removing Alternate Contacts
16.Trusted Advisorの通知設定
Trusted Advisorとは「コスト」「パフォーマンス」「セキュリティ」「信頼性」「サービス制限」の観点でベストプラクティスに則っているかをチェックしてくれるサービスです。
デフォルトで有効になっていますが、ユーザー自身がコンソールなどで能動的に参照する必要があります。 チェック結果は代替連絡先に通知を行うことができます。
定期的に確認したい場合には通知設定を行いましょう。
17.Configの有効化
AWS Configはリソースを軸にどのような変更が加えられたか／他のリソースとの関連を追跡できる構成管理サービスです。
管理できるリソースは以下のドキュメントを参照してください。
AWS Config Supported AWS Resource Types and Resource Relationships
また、ConfigにはConfig Ruleという構成を監視する機能もあり、リソースが適切な状態であることを検知／通知してくれる機能があります。 定義済みのルールも多数あり、必要なルールを有効化しましょう。 独自にルールを定義することも可能です。 ただし、コストには注意しましょう。(ﾁｮｯﾄﾀｶｲ)
List of AWS Config Managed Rules
また、問題のある状態を自動で修正することも可能です。 要件に応じて利用を検討しましょう。
Remediating Noncompliant AWS Resources by AWS Config Rules
18.Health APIによるイベント監視
Personal Health Dashboardは、作成したリソースがメンテナンスの影響を受ける時や大規模障害の影響を受ける場合にそのイベントが表示されます。
CloudWatch Eventsを利用することでイベントを通知することが可能です。
Monitoring AWS Health Events with Amazon CloudWatch Events
19.有効なリージョンの確認
香港リージョンのローンチ以降、新たなリージョンはデフォルトでは無効となります。
デフォルトで無効なリージョンを利用したい場合には有効化しましょう。
Enabling and Disabling Regions
20. 【追加】準拠法／管轄裁判所の変更
通常、AWSのカスタマーアグリーメントでには、準拠法はワシントン州法、管轄裁判所がワシントン州キング郡州裁判所または連邦裁判所とされています。
これを準拠法を日本法／管轄裁判所を東京地方裁判所に変更する場合、従来は個別に書面で契約を交わす必要がありました。 現在ではArtifactで変更することが可能になっています。 詳細は以下のブログをご確認ください。
日本準拠法に関する AWS カスタマーアグリーメントの変更: AWS Artifact
必要であれば変更しましょう。
まとめ
・・・まとめ直してみると以前の倍くらいになってしまいました。
Security Hub / Trusted Advisor / Config Ruleは若干被ってる感がありますが、まずは実際に設定運用してみてから必要な設定に絞ってもいいのではないかと思います。 また、Cost Usage Reportやコスト配分タグもAWSアカウントを目的別に作成して使い分ければそれで十分（請求が分かれる）というケースもあるでしょう。 このあたりは各々でご判断ください。
以上、参考になれば幸いです。 他にやった方がいいことがあれば是非コメントをください。
![[アップデート] Amazon QuickSight へロゴやテーマカラーを設定するための「ブランド管理機能」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
